3. New Features
This section introduces several of the new or improved Client Access Server features.
3.1. Outlook Web App (OWA)
OWA has been renamed from
Outlook Web Access in previous versions of Exchange. OWA allows users
to access their mailboxes using a large number of Web browsers,
including Internet Explorer 6.0+, Firefox, Safari, and Chrome. As with
each new version of Exchange Server, OWA includes more enhancements and
comes even closer to the full client experience. The following list
highlights several of the new features:
Conversation View
MailTips
Instant Messaging Integration with OCS 2007 R2
Predefined Search Filters for quick search of folder contents
Enhanced Right-Click
Attach messages to messages
Another notable change is
with OWA policies. Past versions of Exchange applied OWA policies
against the IIS virtual directory. In Exchange 2010, the policy
settings are now created at a global level, and can be applied per
user. A default policy is created during role installation, but it is
not applied to any mailboxes. The default policy enables all the
options. OWA policies can be applied during a new user creation, or
later on with the Set-CasMailbox cmdlet or EMC.
Service Pack 1 introduces a
new look and feel to simplify the UI and provide a clean view that
emphasizes content. The new interface scales well with different screen
sizes and resolutions, particularly for Netbooks. Figure 2 shows an example of the new interface.
Part of the new
OWA experience is an updated options menu. The most frequently accessed
options are now displayed in a drop-down menu, as shown in Figure 3. Additionally, users now have the ability to apply a theme to OWA.
A very welcome addition in
Service Pack 1 is the ability to print custom calendars in OWA. Users
can view a printable calendar in Daily/Weekly/Monthly/Agenda views.
3.2. RPC Client Access
One of the major new
architectural changes in Exchange 2010 is how RPC (or MAPI) clients
access their mailbox and directory information. Figure 4 illustrates the new Exchange 2010 RPC architecture.
Previously, RPC
clients such as Microsoft Outlook made a connection directly to the
server running the Mailbox role. In Exchange 2010, the Client Access
Server handles the task of processing all RPC requests in place of the
Mailbox server. This is not 100-percent true because public folder
connections still require direct connections to a Mailbox Server role
after being authenticated with the Client Access Server, but these
connections still use the Microsoft Exchange RPC Client Access Service on the Mailbox server.
These changes result in
several benefits. The first advantage is that all Client Access uses a
common route for mailbox access shown in Figure 4-5.
This allows for consistent application of business logic and rules
regardless of the client. Previously, clients either behaved
differently or redundant code sat on multiple tiers. Features that take advantage of change include the Calendar Repair Assistant and the content conversion code.
The second benefit
of channeling client connections through a common path is that it makes
more efficient use of network connections, and provides better scaling
(more users per mailbox server). Using a 64-bit operating system
allowed Exchange 2007 to scale better than previous versions. Removing the traditional bottlenecks (such as memory) allowed new
bottlenecks to appear. TCP connections became a limiting factor when
trying to scale mailbox servers to large numbers of users. A connection
is made up from the source IP address, source port, destination IP address, and destination port. A common issue occurred between the Client Access server and the Mailbox server. On Windows 2003, the Client
Access server can use only a single source port per IP address when
making an outbound connection to another computer. After the source
port has been used, it is not available for any other outbound
connections on the server. This becomes an issue when large numbers of
connections are required, such as when Outlook Anywhere is heavily
used. This was addressed in Windows
2008 by allowing the source port to be used once per source IP address.
By adding additional IP addresses, the Client Access server could scale
past 60,000 connections. However, DSProxy—used to provide directory
access to Outlook clients when connected over Outlook Anywhere—did not
take advantage of this change, and was still limited to 60,000 outbound
connections to global catalog servers. Figure 6 shows the Exchange 2007 connection architecture and where the TCP connection limitations were.
Compare this to the Exchange 2010 situation shown in Figure 7.
The Client Access server now disconnects the user's connection and
saves its session state information. Instead of maintaining a
connection for each user between the Client Access server and Mailbox
server, there is a shared pool of 100 connections. If the user's
connection is not active, it just stays in a disconnected state. This
design allows for the Client Access server to scale better without
having to add additional NICs. The number of shared connections is not
configurable or exposed to administrators, and Microsoft did
significant testing during product development that suggests companies
will not need to change this value. Even though Figure 4-7 shows a Client Access Array, this mechanism operates in the same way with a single Client Access server.
This architectural change also impacts directory access. The Client Access server now implements the Address
Book Service to replace the DSProxy interface on servers with the
Mailbox role. In Exchange 2000 through 2007, DSProxy was a true proxy
and the global catalog provided the NSPI endpoint when clients
connected using Outlook Anywhere. In Exchange 2010, the Client Access
server is the endpoint and makes calls on behalf of the client to the global
directory. Why the significant change? The DSProxy implementation
caused a few issues. One concerned Outlook Anywhere and split connections,
described in detail later in this chapter. At a high level, split
connections could cause a user with Outlook Anywhere to end up with
directory service calls being dropped.
Another common issue was that
Outlook frequently connected to a domain controller that did not hold a
writable copy of a group that users wanted to manage so they got errors
when trying to perform group
management. Several changes were implemented over the years to address
multi-domain DL updates, but the only completely effective solution was
to move all users and distribution lists to the same domain. For most
companies, this is simply not possible, so they end up creating a
complete group management portal,
or using operations processes to control user requests. The Address
Book Service detects modification of DL membership, delegate
management, and certificate management and calls the appropriate
cmdlets to make the necessary changes on a domain controller that has a
writeable copy of the object. The service uses RBAC security to ensure
that the user has the required permissions to make the change. Another
great benefit of the Address Book Service is that future reads from the
client session go to the same domain controller and the change is
reflected immediately.
Previously, users hidden from the Global
Address List (GAL) could not create profiles. The changes in Exchange
2010 also solve this known issue. Now, users can create a profile
whether or not they are hidden from the GAL.
Finally, moving Client Access helps with faster and more seamless failovers, because the client maintains a connection
with the Client Access server, the client is not aware of which mailbox
server is hosting the active database. Therefore, it is possible to
failover a single database instead of requiring the entire storage group, as in Exchange
2007. Microsoft's target failover time before users are reconnected to
their mailboxes in Exchange 2010 is fewer than 30 seconds; CCR was
about 2 minutes.
